Stałe przepływu pracy (Workflow Constants) są funkcjonalnością dostępną wyłącznie w Nintex Workflow dla SharePoint hostowanego na własnej farmie. Służą do przechowywania globalnie używanych zmiennych w jednym miejscu. Mogą być wykorzystywane przez przepływy pracy stworzone w różnych web aplikacjach i kolekcjach witryn na całej farmie SharePoint lub wyłącznie w pojedynczej witrynie – w zależności od poziomu, na jakim zostały zdefiniowane.

istnieją liczne przypadki użycia dla stałych przepływu pracy: przechowywanie danych logowania użytkownika, które są potrzebne do uwierzytelniania w akcjach, przechowywania stałych progów akceptacyjnych, wspólnych dla całej firmy, czy konkretnych dat, które są kluczowe dla procesów operacyjnych przedsiębiorstwa – generalnie, do przechowywania informacji słownikowych.purposes.

Czym jest stała przepływu pracy?

Istnieją trzy poziomy, na których można stworzyć Workflow Constant:

1. poziom farmy (dostępny wyłącznie poprzez Centralną Administrację SharePoint Central: {CA-URL}/_layouts/15/NintexWorkflow/ManageCredentials.aspx?scope=farm&src=/_admin/NintexWorkflow/Management.aspx),
2. poziom kolekcji witryn ({SP-URL}/_layouts/15/NintexWorkflow/ManageCredentials.aspx?Scope=Site),
3. poziom witryny ({SP-URL}/_layouts/15/NintexWorkflow/ManageCredentials.aspx?Scope=Web)

Można wybrać jeden z pięciu typów stałej:

1. String
2. Number
3. Date
4. Credential
5. Secure string

Istnieje także możliwość oznaczenia stałej jako „wrażliwa” (ang. „Sensitive”), dzięki czemu nie będzie istnieć możliwość ujawnienia jej treści przez przepływ pracy (to również bardzo ogranicza możliwości jej użycia). Typy “Credential” i “Secure String” są “wrażliwe” domyślnie. Co więcej, każda stała może mieć ustawione uprawnienia dostępu – domyślnie są widoczne dla każdego użytkownika mającego uprawnienia do tworzenia przepływu, jednak można je ograniczyć do konkretnej listy użytkowników lub grup.

Moje rekomendowane podejście dla migracji stałych

W trakcie migracji Nintex z SharePoint on premise do Office 365, nawet mając Sharegate do pomocy, natrafić można na cały szereg mniejszych i większych wyzwań (poczytaj o tym tutaj: Migracja Nintex Workflow z on-prem do Office 365). W tym wypadku najważniejsze jest jednak to, że… w Office 365 funkcjonalność stałych przepływu pracy w ogóle nie istnieje. To w zasadzie oznacza konieczność wykonania wielu ręcznych operacji, w celu jej odtworzenia.

Podczas migracji Sharegate będzie wyświetlać różne problemy, jakie będzie napotykać, m. in. fakt, że stałe przepływu pracy nie są wspierane podczas migracji. Ta informacja jest klasyfikowana jako „Warning”, dzięki czemu migracja przepływu pracy z tego powodu nie zostanie przerwana, jednak sam przepływ nie zostanie finalnie opublikowany, ponieważ będzie zawierać odwołania do zmiennych, nieistniejących w docelowym środowisku.

Najlepszym sposobem rozwiązania tego problemu jest utworzenie (w zależności od poziomu zmiennej) w bieżącej witrynie lub kolekcji witryn, dedykowanej listy SharePoint o nazwie np.: „WorkflowConstants”. Naturalnie, poziom farmy nie jest dostępny, jednak dla odzwierciedlenia go możesz po prostu utworzyć listę w głównej kolekcji witryn swojego tenanta. W moim przypadku lista jest zbudowana z następujących kolumn (nie muszą to być kolumny witryny, nie ma to tutaj znaczenia):

1. Title (domyślnie istniejąca kolumna)
2. StringVal (zwykła kolumna tekstowa)
3. NumberVal (zwykła kolumna numeryczna)
4. DateVal (zwykła kolumna z datą)

Lista powinna posiadać uprawnienia umożliwiające jej odczyt każdemu użytkownikowi.

Jak zmapować typy?

W zależności od typu, jaki stała przepływu pracy miała w źródłowej konfiguracji, skopiuj i wklej jej wartość do odpowiedniej kolumny na wybranej liście.

W zakresie zmiennej typu „Credentials” – niestety póki co nie istnieje odpowiednik w Nintex dla Office 365, aczkolwiek praca nad podobną funkcjonalnością została niedawno rozpoczęta (https://nintex.uservoice.com/forums/218291-3-nintex-workflow-for-office-365/suggestions/7012107-secure-password-variable).

Odnośnie zmiennej typu “Secure string” – powinna zostać skopiowania do kolumny “StringVal”.

Jak zmapować uprawnienia?

Jeśli stała była oznaczona jako dostępna dla każdego („Everyone”), wówczas żadnych zmian dla elementu ją odzwierciedlającego nie trzeba wykonywać.

W przypadku, gdy była ustawiona jako dostępna wyłącznie dla określonych użytkowników, wówczas należy otworzyć ustawienia uprawnień wybranego elementu listy, zerwać je i ustawić na takie, by odzwierciedlały źródłowe.

[tds_warning]    Niestety rozwiązanie to nie pozwoli na odwzorowanie zachowania z Nintex on premise – użytkownik, nawet nie mając uprawnień do elementu, będzie w stanie opublikować workflow, który daną zmienną używa, aczkolwiek będzie ona posiadać pustą wartość.[/tds_warning]

Jak zmapować „wrażliwość”?

Podobnie jak w przypadku uprawnień, najlepszym podejściem jest zerwanie dziedziczenia uprawnień i ustawienie praw dostępu dla wąskiej grupy użytkowników.

[tds_info]    Sugeruję wykonywanie operacji na zmiennych odwołujących się do takich elementów z użyciem akcji „opakowującej” zwanej „Action Set”, z włączoną opcją „Elevate permissions”, dzięki czemu zawarte w niej akcje zostaną wykonane z uprawnieniami aplikacji, jednak poza blokiem będą zwracać puste wartości.[/tds_info]

Jak użyć tak przygotowanych zmienny w przepływie?

Najprostszym sposobem jest dodanie akcji „Set workflow variable”, a następnie dla każdej, używanej w przepływie stałej, utworzenie odpowiadającej jej zmiennej przepływu pracy i ustawienie jej wartości, poprzez „Advanced Lookup”, wybierając wartość z pola o konkretnym typie i filtrując używając tytułu:

Przepływ się zawiesza?

Miej na uwadze fakt, iż używanie lookupu do odwołania się do listy stałych, nie jest podczas procesu publikacji przepływu w żaden sposób weryfikowane przez Nintex. Aplikacja nie sprawdza, czy użytkownik tworzący workflow posiada uprawnienia dostępu do zasobów, do jakich się odwołuje. Problemy zatem zaczną się pojawiać dopiero w momencie próby uruchomienia przepływu, gdy odwołanie zostaje wykonane. Toteż jeśli stała jest kluczowa dla poprawnego działania przepływu pracy, cały proces może się zawiesić (Suspended), z powodu błędu dostępu do zmiennej/ pustej zmiennej.

[tds_note]    Niestety aktualnie nie istnieje lepsze rozwiązanie, by symulować istnienie stałych przepływu pracy, także upewnij się, że wszystkie krytyczne akcje są wstawione do środka akcji „Action Set”, mającej podniesione uprawnienia i przetestuj działanie przepływu korzystając konta posiadającego uprawnienia identyczne jak zwykły użytkownik, który docelowo będzie pracować z przepływem.[/tds_note]

 

Zapraszam Cię także do dyskusji w komentarzach i dzielenia się swoimi rozwiązaniami dla przenoszenia stałych przepływu pracy z on premise do Office 365.